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TITLE OF THE INVENTION 

GENERIC METHOD FOR CUSTOMIZATION OF DHCP 

OPTIONS 

5 

FIELD OF THE INVENTION 

The present invention relates to Dynamic Host Control Protocol 
(DHCP). More specifically, the present invention is concerned with a generic 
1 0 method for customization of DHCP options. 

BACKGROUND OF THE INVENTION 

The Dynamic Host Control Protocol (DHCP) is a well-known 
15 text-based protocol that functions over the Internet protocol layer. DHCP 
allows to configure networking equipment, and to assign dynamic IP 
addresses from a pool of addresses to DHCP clients. Alternatively, DHCP 
may allow network administrators to assign static addresses manually. Clients 
can thus identify themselves using a unique key, for example, the MAC 
20 (Media Access Control) address, which is a globally assigned number for all 
network-enabled hardware devices. 

Along with its assigned IP address, a DHCP client is subject to 
receive other useful configuration information. Most of the DHCP information, 
25 called options in DHCP lore, is registered with the IANA (Internet Assigned 
Numbers Authority). 
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Figure 1 of the appended drawings illustrates the typical DHCP 
message structure, as defined by the IANA. The lengths, in bytes, of the 
fields 12 of the static structure 10 illustrated in Figure 1 are found in 
parentheses. 

5 

The standard format of DHCP options, which can be found in 
the "options" field 14 on Figure 1, is illustrated in Figure 2. 

The options field 14 of the DHCP message 10 contains the 
10 various options required for the session, as stored by an IP application. 
Typically, the client can ask for specific options, and normally, servers are 
pre-configured to give out specific options as well. 

The options field 14 of a DHCP message includes three 
15 subfields: a "code" subfield 16, a "len" subfield 18, and a data subfield 20. 

The code subfield 16 identifies the options and is one byte long 
(as is indicated in parentheses). Possible "code" values therefore lie in the 
range [0, 255]. Such values are also known as "opcodes". 

20 

In particular, the options identified by the values 0 and 255 are 
respectively "Pad" and "End" options. These two DHCP options are 
exceptions, as they do not have the typical structure of DHCP options. The 
"Pad" and "End" options facilitate encoding and decoding of DHCP options 
25 in a DHCP message. Since these two options are believed to be well known 
in the art, they will not be described herein in further detail. 
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Furthermore, as it is commonly known in the art, the options 
identified by opcodes ranging in [1, 127] are dedicated to IAN A assignations. 
It is to be noted that most of these assignations are already predetermined. 
On the contrary, the range [128, 254] is unassigned and cannot be assigned 
5 through the IANA. Opcodes in this range are called site-specific opcodes, and 
are purely application specific. Any application may customize any of these 
opcodes. Lastly, the opcode 43 identifies the vendor-specific option. 

An example of a DHCP option assigned by the IANA is the 
10 option specifying the subnet mask, identified by the opcode 1 . This option is 
in the form of an IP address and its length is therefore set to 4 bytes. 

Figures 3 and 4 respectively illustrate the vendor-specific (43) 
and site-specific ([128, 254]) options structures 22 and 24. 

15 

As can be seen by comparing Figures 3 and 4 to Figure 2, the 
structures of the vendor-specific 22 and site-specific options 24 have 
generally the same format as an IANA designated DHCP option 14. 
However, the format of their "data" fields, respectively 26 and 28, are 
20 application-specific, i.e. it can be specified by the application requiring the 
DHCP client. 

Indeed, since the format of data fields 26-28 are not defined by 
IANA, any format required by the IP application using a DHCP client may be 
25 chosen for these fields. However, as an implicit convention in the art, the 
vendor-specific and site-specific options are encoded in a DHCP message as 
a sequence of code/length/data fields, identical in syntax to the other DHCP 
option fields (see Figure 2). 
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The site and vendor specific options 22-24 allow extending the 
possibility of the DHCP. However, since their format and content may vary 
depending on the IP application that requires them, these options require 
5 rewriting a code from one application to another in order to interpret the 
content of the corresponding option fields. 

For example, Internet Protocol (IP) telephony products, and 
more specifically, network-enabled embedded devices, such as the Mediatrix 
10 1 124 from Mediatrix Telecom Inc., rely on DHCP information for configuration 
in accordance to the local network. 

Generally, different software applications running in such 
devices or other similar devices requires different implementations of their 
15 DHCP option retrieval methods. This can be seen as a drawback, since each 
time it requires rewriting code to parse and create DHCP option fields. 

SUMMARY OF THE INVENTION 

20 More specifically, in accordance with the present invention, 

there is provided a method for customization of Dynamic Host Control 
Protocol (DHCP) options, the method comprising: 
providing a library of data types; and 

defining a DHCP option as an optionrule; the optionrule 
25 including an opcode identifying the DHCP option, and at least one datarule; 
the at least one datarule including one of one of the data types and an 
optionrule. 
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According to a second aspect of the present invention, there 
is further provided a method for configuring an Internet Protocol (IP) 
application to use Dynamic Host Control Protocol (DHCP) options, the method 
comprising: 
5 providing a library of data types; 

registering a list of opcodes to be used by the IP application; 
each of the opcodes identifying a DHCP option; and 

registering optionrules corresponding to the opcodes; each of 
the optionrules including an opcode identifying the DHCP option, and at least 
1 0 one datarule; the at least one datarule being defined by one of one of the data 
types and an optionrule. 

According to a third aspect of the present invention, there 
is also provided a method for communicating Dynamic Host Control Protocol 
15 (DHCP) messages between a DHCP server and an Internet Protocol (IP) 
application, the method comprising: 

a) accessing a library of data types; 

b) upon sending a DHCP message from the IP application to 
the DHCP server: 

20 - retrieving an option list including options to encode and an 

opcode for each of the options ; 

- for each of the opcodes: 

b)i) retrieving an optionrule corresponding to the current 
opcode; the optionrule including at least one datarule; the at least one 
25 datarule being defined by one of one of the data types and an optionrule; 

b)ii) retrieving data corresponding to each of the options 
in the option list; and 
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b) iii) encoding, in the DHCP message to send, each of 
the retrieved data in a DHCP options field identified by the opcode, by 
interpreting the optionrule using the datarule and the library of data types; 
and 

5 c) upon receiving a DHCP message to the IP application from 

the DHCP server: 

-retrieving in the received DHCP message, a list of opcodes 

to decode; 

- for each of the opcodes in the opcode list: 
1 0 c)i) retrieving an optionrule corresponding to the current 

opcode; and 

c) ii) for each optionrule, decoding in the received DHCP 
message data corresponding to the opcode, by interpreting the optionrule 
using the datarule and the library, yielding decoded DHCP data. 

15 

Other objects, advantages and features of the present 
invention will become more apparent upon reading the following non 
restrictive description of preferred embodiments thereof, given by way of 
example only with reference to the accompanying drawings. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the appended drawings: 

25 Figure 1, which is labelled "prior-art", is a schematic view 

illustrating a DHCP message structure; 

Figure 2, which is labelled "prior-art", is a schematic view 
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illustrating a DHCP option structure in the DHCP message of Figure 1; 

Figure 3, which is labelled "prior-art", is a schematic view 
illustrating the vendor-specific option field in the DHCP message of Figure 1 ; 

5 

Figure 4, which is labelled "prior-art", is a schematic view 
illustrating the site-specific data field structure in the DHCP message structure 
of Figure 1 ; 

10 Figure 5 is a flowchart illustrating a method for customization 

of DHCP options, according to an embodiment of the present invention; 

Figures 6a-6c are schematic views illustrating examples of 
option rules according to embodiments of the present invention; 

15 

Figure 7 is a flowchart illustrating a method for configuring an 
IP application for using DHCP options, according to an embodiment of the 
present invention; and 

20 Figure 8 is a flowchart illustrating a method for communicating 

DHCP messages between an IP application and a DHCP server during a 
DHCP session, according to an embodiment of the present invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

25 

Turning now to Figure 5 of the appended drawings, a method 
100 for customization of DHCP options for an IP application, according to a 
first aspect of the present invention, is illustrated. 
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Generally stated, the method 100 consists in performing the 
following steps in sequence: 

5 102 - providing a library of data types; 

104 - defining each DHCP option as an optionrule; and 

106 - storing the optionrule in an option field of a DHCP 

message. 

10 Each of these steps will now be described in further detail. 

In step 102, a library of basic data types is provided. As will be 
explained in more detail hereinbelow, these data types will be used as atomic 
data items to characterize the data element in data subfields 20, 26 and 28 
15 in a DHCP message (see Figures 2,3 and 4). 

A library of data types is advantageous because some data 
types in the DHCP specification are redundant. Examples of such redundant 
data are IP addresses in numeric or dotted string form, token strings that need 
20 to be matched, integer values, etc. 

The following is an example of a library of data types according 
to an embodiment of the present invention, in the Augmented Backus-Naur 
Form (ABNF): 

25 

Dhcp Option = Option Rule 

OptionRule = Opcode [ Length *DataRule ] 

Length = (0x00 -OxFF) 
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Opcode = (0x00 - OxFF) 

DataRule = (TerminalType | OptionRule ) 

TerminalType = ( Bool | Byte | Dword | Word | MultipleBool | MultipleByte 
| MultipleDword | MultipleWord | VarLenlntegerString | IpAddr | DottedlpAddr 
5 | MultiplelpAddr | String | VarLenString | TokenString | Extensionltem ) 

Bool = (0x00 | 0x01) 

Byte = (0x00 - OxFF) 

Dword = (0x00000000 - OxFFFFFFFF) 

Word = (0x0000 - OxFFFF) 
10 MultipleBool = 2*Bool 

MultipleByte = 2*Byte 

MultipleDword = 2*Dword 

MultipleWord = 2*Word 

VarLenlntegerString = 1*10(DIGIT) 
1 5 IpAddr = (0x00000000 - OxFFFFFFFF) 

DottedlpAddr = 3(1*3DIGIT V) 1*3DIGIT 

MultiplelpAddr = 2*lpAddr 

String = 1*n(CHAR) 

VarLenString = 1*(CHAR) 
20 TokenString = String (The token is specified and must be matched 

exactly) 

Extensionltem = New data type. 

Example of a library of data types 

25 



The above example of library data types shows that even 
complex data items can be decomposed into a number of simpler data items. 
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Obviously, other data types may be defined in the library 
depending on the requirements of the IP application. 

In the following, a data type will be said to be terminal if it can 
5 be used directly to encode/decode information in a DHCP message. 

Of course, the IP application is advantageously provided with 
a DHCP client that is configured with instructions for translating the data 
types, so as to encode/decode DHCP information in the data subfield of a 
10 DHCP option. 

The concepts of datarule and optionrule will now be described. 

A datarule is used to indicate to an appropriately configured 
15 DHCP client a rule allowing to encode and decode an atomic item. Each 
datarule characterizes one or more data items in a DHCP option and includes 
the type of the data items (for example, a byte, an integer, a string of 
characters, etc.) as defined in the library. 

20 Indeed, a great deal of diverse information may be associated 

with a DHCP option, especially with vendor-specific and site-specific options. 
A datarule is advantageously associated with each complete information 
required by a DHCP option. Since such complete information may include 
more than one element of information, a datarule may include one or more 

25 data items, globally resulting in one of the information required by a DHCP 
option. 

In addition to the type of the data items, a datarule may also 
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include other typical characteristics of data items in a DHCP option. Examples 
of these characteristics are: mandatory status (must this data item be 
absolutely present for the option to be valid?), the maximum/minimum/fixed 
length of the data field, or a predetermined value to find for this data item (for 
5 example, must equal "1" or a certain character string). For example, to 
represent a Datarule that must be equal to the string "Mediatrix", we would 
create a datarule with the type TokenString (see the above example of library 
of data types) and assign "Mediatrix" to the token. When decoding, the library 
will then look for the specific word "Mediatrix". Of course, other characteristics 
10 may also be used. 

Other types of information may also optionally be present in a 
datarule to help with other tasks related to the encoding and decoding of the 
DHCP option. For example, a unique identificator can be included for the data 

15 item. This identificator is to be used with a separate mechanism, 
implemented in the IP application, for retrieving the data to encode and store 
the data that was parsed. That identificator would also uniquely identify a 
database item that would be the decoded value for the datarule, which can be 
used by the IP enabled application. The IP enabled application is configured 

20 to access the decoded information by knowing the identificator that was 
assigned to the datarule. Similarly, for encoding, the application sets the 
value in the database using the identificator, and the encoding entity (the code 
library) gets the value from the database before encoding it. 

25 The DHCP protocol states that more than one DHCP server 

can answer a DHCP client's request (the DHCP client's request is typically 
broadcasted over the local network). In that case, the client uses an 
application-specific algorithm to choose which server the DHCP client will 
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acknowledge. A typical way of doing this is to assign a value to every DHCP 
option that is found in the server's response, and then select the server that 
best suits the client's needs. This can be easily achieved by extending a 
datarule to contain not only an identificator that maps it to a database, but 
5 also a value for this datarule's presence in the DHCP message. For example, 
the assigned IP address would have a higher presence value than the subnet 
mask, and so if having to choose between these two messages, a DHCP 
client would chose the IP address. The server's proposal can be weighed by 
the total of its datarule's values. The assigned value will also be referred to 
1 0 herein as a server-choosing algorithm identificator. 

An optionrule includes an opcode identifying the DHCP option, 
and at least one datarule specifying the format of the optionrule data field. 

15 Optionally, an optionrule includes other information such as 

mandatory state and a server-choosing algorithm identificator. 

In some cases, an optionrule may be considered invalid, and 
therefore unusable, if one of its datarules is invalid. 

20 

Figures 6a and 6b illustrate two examples of implementation of 
the method for customization of DHCP options according to a preferred 
embodiment of the present invention. 

25 A first example is given in Figure 6a. The optionrule 108 for the 

subnet option, corresponding, according to IANA, to the opcode 3, is 
illustrated. As can be seen in Figure 6a, the optionrule 108 includes the 
opcode value 3 (reference number 110), and a single datarule 112, which 
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specifies in this particular case that the type of data expected for the subnet 
option is IpAddr, as defined in the library provided in step 102. This data type 
corresponds to an IP address in digital format. 

5 A second example is illustrated in Figure 6b. In this example, 

the optionrule 1 14 for the message type, corresponding to the opcode 53, is 
illustrated. As can be seen in Figure 6b, the optionrule 114 includes the 
opcode value 53 (reference number 116), and a single datarule 118, which 
specifies here that the type of data expected for the message type is byte, as 
10 defined in the library provided in step 102. Expected values for this optionrule 
are defined in the DHCP standard. 

As can be seen from the above two examples of optionrules, 
optionrules and datarules may advantageously be used to encode and 
15 decode DHCP options defined and assigned by IANA, in addition to vendor 
and site-specific options. 

Since the DHCP subnet and message type options are 
believed to be well known in the art, they will not be described herein in further 
20 detail. 

As can be seen in the above example of library (step 102), the 
optionrule is advantageously defined as a data type. Considering the 
optionrule as an atomic item advantageously allows to create optionrules in 
25 which the data field is composed of one or more optionrules as in the vendor- 
specific option. Thus, the optionrule may become a basic type that can be 
used to specify datarules. In that case, in contrast with other basic types of 
datarules, optionrules that are used as a basic type of a datarule does not 
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have an associated database identificator, since they are not used to map 
directly to one single data item. 

A further example of an optionrule will now be presented. 
5 Figure 6c of the appended drawings illustrates an example of an optionrule 
that includes a data field composed of optionrules. 

The optionrule 120 includes the opcode value 43 (reference 
number 122), corresponding to a vendor-specific option. 

10 

The optionrule 120 further includes two datarules 124 and 126, 
each defining the expected data type as being optionrules. thus, this example 
illustrates a possible implementation of the vendor-specific option allowing to 
decode/encode optionrules corresponding to site-specific options 
15 corresponding to both the opcodes 129 and 152 (respectively labelled 128 
and 130). 

The optionrules labelled 128 includes the datarules labelled 
132 defining the expected value for the corresponding option as being defined 
20 by an IP address (type IpAddr in the library), while the optionrules labelled 130 
includes the datarules labelled 134 defining the expected value for the 
corresponding option as being defined as a byte. 

It is to be noted that the datarules 124 and 126 in the optionrule 
25 1 20 are not terminal since they define the expected values for this data field 
as being optionrules. The two datarules 132 and 134 are, however, terminal. 

As illustrated in the above examples, datarules and optionrules 
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are used for specifying the format, and optionally the container for the 
encoded/decoded data. 

As stated hereinabove, the DHCP client that is used to encode 
5 and decode the DHCP options is configured so as to use the above-described 
library of data types to encode and decode optionrules according to the 
present invention. 

The library advantageously includes sufficiently flexible data 
10 types for the datarules so that the DHCP client should not require any 
changes from one application to another. 

Accordingly, to handle new DHCP options, appropriate 
datarules are created and associated to an optionrule for a particular purpose 
15 of the IP application. 

Thus, the present invention allows customization of DHCP 
clients by providing a generic way of adding new DHCP options by pre- 
defining the data types for the options. 

20 

In accordance with this design, any user of the DHCP client is 
enabled to change the list of supported DHCP options, and to redefine vendor 
and site-specific data field formats to suit their application's needs. 

25 The method for customization of DHCP options, according to 

the present invention, is advantageously based on a reusable code, therefore 
avoiding the writing of an unnecessary code in order to parse and/or create 
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DHCP options. Moreover, the method provides a means to express more 
complex DHCP options without any changes in the core source code. 

Turning now to Figure 7, a method for configuring an IP 
5 application for using DHCP options, according to a second aspect of the 
present invention, is illustrated. 

It will be apparent that the method 200 of Figure 7 is 
implemented in a computer system (not shown) in the form of hardware or 
1 0 software. More specifically, the method is advantageously implemented in the 
context of a DHCP client (not shown). 

Indeed, in addition to the IP application, the computer system 
advantageously includes a DHCP client in order to communicate DHCP 
1 5 messages to a DHCP server. 

The computer system, IP application and DHCP client may all 
be in the form of a single IP product, for example, a network-enabled 
embedded device, such as an Internet phone adapter. The Mediatrix 1124 
20 from Mediatrix Telecom Inc. is an example of such an IP product. 

Since a DHCP client and a DHCP server are believed to be 
well known in the art, and for concision purposes, they will not be described 
herein in further detail. 

25 

Generally stated, the method 200 consists in performing the 
following steps: 
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202 - initializing the IP application; 
204 - providing a library of data types; 
206 - registering the list of opcodes to be used by the IP 
application; and 

5 208 - registering optionrules corresponding to the opcodes. 

Obviously, before configuring the IP application to use DHCP 
options, the IP product or IP application has to boot. 

10 Each of the steps of method 200 will now be described in 

greater detail. 

In step 202, the IP application is initialized. Step 202 
advantageously includes: initialization of the IP stack (to prepare to send 
15 DHCP messages) and other non-DHCP related bootup tasks such as 
provisioning, etc. 

As will be explained hereinbelow, the method 200 makes use 
of the concept of datarules and optionrules, as described hereinabove, and 
20 as is obvious, also makes use of the library of data types. Therefore, the pre- 
defined library of data types is provided so as to be accessed by the DHCP 
client. In step 204, the library is either stored in a Random Access Memory 
(RAM) of the system or is pre-programmed into the system. 

25 Of course, the library of data types defines data types 

necessary to encode and decode the DHCP options required by the IP 
application and is therefore compatible with it. 
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Obviously, step 204 may be included in the initialization step 

202. 

In step 206, the list of opcodes to be used by the IP application 
5 is registered. Similarly to the library of data types, the opcode list is made 
available to the DHCP client. A correspondence table is advantageously 
provided to associate opcode values to corresponding DHCP options. 
Alternatively, a list of options may directly be provided. 

10 It is to be noted that the expression "registering" will be used 

herein as the action of making the corresponding information available to the 

IP application and/or to the DHCP client 

i 

The list of opcodes is previously stored in the system that 
15 includes the IP application, or is alternatively pre-programmed in the IP 
application code. The opcode may also be selected from a more thorough list 
using, for example, a user interface. This advantageously allows easy 
configuration of the IP application according to, for example, user 
preferences. Where the IP application is implemented in software form in a 
20 computer system, a conventional menu list may be used by the user of the IP 
application to select appropriate DHCP options. 

In step 208, optionrules corresponding to the opcodes 
registered in step 206 are registered. In addition to an identifying opcode, 
25 each optionrule includes at least one datarule, as explained hereinabove. 

Attention is drawn to the fact that the method 200 
advantageously allows the DHCP client (and thus the IP application) to be 



WO 02/100070 



PCT/CA01/01626 



19 



configured to encode and decode DHCP messages. 

Turning now to Figure 8 a method 300 for communicating 
DHCP messages between an IP application and a DHCP server during a 
5 DHCP session, according to a further aspect of the present invention, is 
illustrated. 

Generally stated, the method 300 consists in performing the 
following steps: 

10 

upon sending a DHCP message from the IP application to the 

DHCP server 

302 - providing an option list, including an opcode for each 
of the options in the list; 
1 5 for each of the opcodes: 

304 - retrieving an optionrule corresponding to the 

opcode; 

306 - retrieving datarules related to the retrieved 

optionrule; and 

20 308 - encoding, in the DHCP message to send, each of 

the datarules, by interpreting the optionrule, using the library of data types; 
and 

upon receipt of a DHCP message from the DHCP server to the 

IP application: 

25 310 - retrieving, in the received DHCP message, a list of 

opcodes to decode; 

312 - for each opcode in the list, retrieving an optionrule 
corresponding to the opcode that needs to be decoded; and 



WO 02/100070 



PCT/CA01/01626 



20 



for each option rule: 

314 - decoding, in the received DHCP message, data 
corresponding to the opcode, by interpreting the optionrule using the library; 
and optionally 
5 31 6 - storing the decoded data. 

As with the configuration method 200 described hereinabove, 
the DHCP client (and thus the IP application) has access to the library of data 
types for the communication method 300. 

10 

Each of the steps of the method 300 will now be described in 

further detail. 

As can be seen in Figure 8, the method 300 may actually be 
1 5 divided into two methods: a method for encoding a message to be sent by the 
IP application to a DHCP server (302-308), and a method for decoding a 
DHCP received by the application from the DHCP server (310-316). 

Although each of these two processes uses the library of data 
20 types, optionrules and datarules, they may be executed independently. 

Steps 302-308 concern the encoding DHCP options upon the 
IP application sending a DHCP message to the DHCP server. 

25 In step 302, a list of options is provided for encoding. As has 

been discussed hereinbelow, the list of opcodes is preferably provided to the 
DHCP client during the configuration process 200, but it can also be provided 
before encoding the options. 
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The list of options also includes a corresponding opcode value 
for each option. It is to be noted that options are uniquely identified by their 
opcode. 

Steps 304-308 are performed for each opcode. 



In step 304, an optionrule corresponding to the current opcode 
is retrieved. As discussed hereinabove, the optionrule includes at least one 
1 0 datarule defined by either of the data types or an optionrule. 

In step 306, the data related to the corresponding options is 
also retrieved. 

15 The list of opcodes, the optionrules and the data may have 

been previously stored in the system that includes the IP application (or in a 
memory of the IP product). Alternatively, it is included in the IP application 
code. The opcode list may also be selected from a more thorough list using, 
for example, a user interface. Providing the opcodes, a table of 

20 correspondence may provide the corresponding optionrule and data. 



The retrieved data is then encoded in the DHCP message to 
be sent by interpreting the optionrules using the library of data types (step 
308). 

25 

The second method comprised in method 300 is described 
through steps 310-316. It concerns the decoding of DHCP options upon the 
IP application's receipt of a DHCP message from the DHCP. 
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In step 310, a list of options to decode with corresponding 
opcodes is retrieved in the option field of the received DHCP message. 
However, it is to be noted that the list of options is usually already known by 
5 the DHCP client, since the DHCP message is received in response to a 
previous DHCP message sent by the DHCP client to the DHCP server (see 
steps 302-308). 

Steps 312 to 316 are performed for each of the retrieved 

10 opcodes. 

The list of options is then used to associate an optionrule and 
an opcode corresponding to each option in the list (312). 

15 In step 314, the data included in the option field of the received 

DHCP message is decoded by interpreting the optionrules associated with the 
current opcode, using the library of data types. 

The decoded data is then preferably stored for later retrieval by 
20 the IP application. The data is advantageously stored in Random Access 
Memory (RAM) of the system hosting the IP application (or in the a memory 
of the IP product). Alternatively, any other memory means may be used, 
including Read Only Memory (ROM), cache, swap files, local storage means, 
etc. 

25 

As illustrated in Figure 8, a test may be performed during the 
encoding or decoding process to assess whether all DHCP options to 
encode/decode have been processed. 
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If any error is found during the communication process 300, the 
IP application is advantageously configured to display an error message on 
a display device. 

5 

Since datarules are defined using a library of predefined data 
types, the length of the data in the DHCP options data fields is implicitly 
defined by specifying the data type. 

10 The methods 100, 200 and 300 are advantageously 

implemented in C++. Alternatively, other languages may also be used without 
departing from the spirit and nature of the present invention. 

The present invention can be used to create any kind of 
1 5 parsers/encoders for text-strings. 

Although the present invention has been described 
hereinabove by way of preferred embodiments thereof, it can be modified 
without departing from the spirit and nature of the subject invention, as 
20 defined in the appended claims. 
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WHAT IS CLAIMED IS: 



1. A method for customization of Dynamic Host Control 
Protocol (DHCP) options, the method comprising: 

5 providing a library of data types; and 

defining a DHCP option as an optionrule; the optionrule 
including an opcode identifying the DHCP option, and at least one datarule; 
the at least one datarule including one of one of the data types and an 
optionrule. 

10 

2. A method as described in claim 1, further comprising 
storing the optionrule in an option field of a DHCP message. 

3. A method as described in claim 1 f wherein said library of 
15 data types includes terminal data types and optionrules. 



4. A method as decribed in claim 1, wherein the DHCP option 
to customize is selected from site-specific options, vendor-specific options 
and lANA-assigned options. 

20 

5. A method as decribed in claim 1, wherein said optionrule 
includes more than one datarule. 



6. A method as decribed in claim 1 , wherein said at least one 
25 datarule further includes a mandatory status. 
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7. A method as decribed in claim 1 , wherein said at least one 
datarule further includes information related to the length of a datafield of the 
DHCP option to customize. 

5 8. A method as decribed in claim 1 , wherein said at least one 

datarule further includes a predetermined value to be found for a 
corresponding data item. 

9. A method as decribed in claim 1 , wherein said at least one 
10 datarule further includes a unique identificator. 

10. A method as decribed in claim 9, wherein said unique 
identificator is to be assigned by a DHCP client to a DHCP option found in a 
DHCP server's response, thereby allowing said DHCP client to identify and 

15 select a DHCP server according to said DHCP server's response. 

1 1 . A method as described in claim 1 , wherein said optionrule 
further includes one of a mandatory state and a server-choosing algorithm 
identificator. 

20 

12. A method for configuring an Internet Protocol (IP) 
application to use Dynamic Host Control Protocol (DHCP) options, the method 
comprising: 

providing a library of data types; 
25 registering a list of opcodes to be used by the IP application; 

each of the opcodes identifying a DHCP option; and 

registering optionrules corresponding to the opcodes; each of 
the optionrules including an opcode identifying the DHCP option, and at least 
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one datarule; the at least one datarule being defined by one of one of the data 
types and an optionrule. 

13. A method as recited in claim 12, further comprising 
5 initializing the IP application before registering the list of opcodes to be used. 

14. A method as recited in claim 12, wherein said IP 
application includes a DHCP client. 

10 15. A method as recited in claim 14, wherein said initializing 

includes initialization of a IP stack of the DHCP client. 

16. A method as recited in claim 12, wherein a correspondence 
table is used to associate each of said opcodes values to a corresponding 

15 DHCP option. 

17. A method as recited in claim 12, wherein said list of 
opcodes is pre-programmed in said IP application. 

20 18. A method as recited in claim 12, wherein said list of 

opcodes is selected using a user interface provided by the IP application. 

19. A method for communicating Dynamic Host Control 
Protocol (DHCP) messages between a DHCP server and an Internet Protocol 
25 (IP) application, the method comprising: 

a) accessing a library of data types; 

b) upon sending a DHCP message from the IP application to 
the DHCP server: 
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- retrieving an option list including options to encode and an 
opcode for each of the options ; 

- for each of the opcodes: 

b)i) retrieving an optionrule corresponding to the current 
5 opcode; the optionrule including at least one datarule; the at least one 
datarule being defined by one of one of the data types and an optionrule; 

b)ii) retrieving data corresponding to each of the options 
in the option list; and 

b) iii) encoding, in the DHCP message to send, each of 
10 the retrieved data in a DHCP options field identified by the opcode, by 

interpreting the optionrule using the datarule and the library of data types; 
and 

c) upon receiving a DHCP message to the IP application from 
the DHCP server: 

1 5 -retrieving in the received DHCP message, a list of opcodes 

to decode; 

- for each of the opcodes in the opcode list: 

c) i) retrieving an optionrule corresponding to the current 

opcode; and 

20 c)ii) for each optionrule, decoding in the received DHCP 

message data corresponding to the opcode, by interpreting the optionrule 
using the datarule and the library, yielding decoded DHCP data. 

20. A method as recited in claim 19, wherein at least one of 
25 said opcode list, said optionrules and said data is stored in a computer system 
that includes the IP application. 
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21. A method as recited in claim 19, wherein said opcode list 
is selected using a user interface provided by the IP application. 

22. A method as recited in claim 19, wherein said optionrules 
5 corresponding to opcodes are retrieved using a table of correspondence. 

23. A method as recited in claim 19, wherein said decoded 
data is stored for later retrieval by the IP application. 

10 24. A method as recited in claim 23, wherein said decoded data 

is stored in one of Random Access Memory (RAM), Read Only Memory 
(ROM), cache, swap files, and local storage means. 
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